Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/networking/terms/kermit/e/v11.3

Text File | 1990-01-18 | 26.7 KB | 511 lines

19-Jan-90  2:27:30-GMT,27278;000000000001
Return-Path: <fdc>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA08698; Thu, 18 Jan 90 20:54:35 EST
Date: Thu, 18 Jan 90 20:54:34 EST
From: Frank da Cruz <[e-mail]>
To: [e-mail]
Subject: Info-Kermit Digest V11 #3
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Thu, 18 Jan 1990        Volume 11 : Number 3

Today's Topics:
                     Announcing MS-DOS Kermit 3.0
               MS-DOS Kermit 3.0 Questions and Answers
                   New MS-DOS Kermit Book Available
                  MS-DOS Kermit 3.0 Feedback Wanted
               Announcing HP-1000 Kermit Version 1.99D
              Query: C-Kermit Treatment of Modem Signals

Digest submissions may be sent to [e-mail],
requests for addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280
running UNIX (SUNOS 4.0), IP host number 128.59.39.2.  Login as user
anonymous (note, lower case), any password, and GET or MGET (MULTIPLE GET)
the desired files.  The Kermit files are in directories kermit/a, kermit/b,
kermit/c, kermit/d, and kermit/e.  Test versions are in kermit/test.  You
can also get Kermit files over the BITNET/EARN network; to get started send
a message with text HELP to KERMSRV, the Kermit file server, at host CUVMA.
For detailed instructions, read the file kermit/a/aanetw.hlp (AANETW.HLP on
KERMSRV).  To order by mail, request a complete list of Kermit versions and
an order form from Kermit Distribution, Columbia University Center for
Computing Activities, 612 West 115th Street, New York, NY 10025 USA.

[Ed. - And apologies for the I-KERMIT ADD message mistakenly sent to I-KERMIT
instead of LISTSERV.  Some day I'll learn!]

----------------------------------------------------------------------

Date: Thu, 18 Jan 1990 12:00:00 EST
From: Christine M Gianone <[e-mail]>
Subject: Announcing MS-DOS Kermit 3.0
Keywords: MS-DOS Kermit 3.0

This is to announce the final release of MS-DOS Kermit 3.0, first announced
for beta-testing in Info-Kermit V11 #2.  Thanks to the thousands of you who
participated in the short testing period.  To recapitulate the major new
features of 3.0, they are:

 . DEC VT320 terminal emulation.
 . Many additions to Tektronix graphics emulation, including features
   from the DEC VT340 (color, sixel, but not REGIS) and HDS2000/3000,
   suitable for use with mainframe versions of WordPerfect 4.2 and 5.0.
 . Saving of graphics screens on disk in TIFF 5.0 format, suitable for
   import into PC Paint, Ventura Publisher, Pagemaker, WordPerfect 5.0, etc.
 . True half duplex operation with RTS/CTS hardware handshake.
 . International character set support for both terminal emulation and
   file transfer.
 . Sliding window packet protocol.

Problems reported and fixed during the testing period include:

 . Incorrect Attribute packet character set announcers.
 . Problems when receiving badly formatted packets 1800-2000 bytes in length.
 . Incorrect receive packet length after SET WINDOWS command.
 . Incorrect crosshair cursor report in Tektronix mode.
 . Automatic return to wrong text terminal type after Tektronix emulation.
 . Several incorrect special terminal character translations.
 . Incorrect operation of SET TRANSLATE INPUT.
 . Terminal lockup after failure to automatically enter 132-column mode.
 . Insufficient maximum allowed number of ANSI escape sequence parameters.
 . Nonfunctional 3COM BAPI network support.
 . Case sensitivity of ARGC, VERSION, and other special numeric variables.
 . Various minor escape sequence misinterpretations.

The new files have been installed in the regular Kermit distribution "A" area,
and are available over the networks via anonymous FTP from
watsun.cc.columbia.edu (Internet) and from KERMSRV at CUVMA (BITNET), and by
mail order from Kermit Distribution at Columbia University on a variety of
magnetic media.

Internet      BITNET        Description
 msvibm.boo    MSVIBM.BOO    BOO-encoded (printable) version of MSVIBM.EXE.
 mskerm.hlp    MSKERM.HLP    Summary of MS-DOS Kermit 3.0 features & commands.
 msr300.upd    MSR300.UPD    Description of new features in version 3.0.
 mskerm.bwr    MSKERM.BWR    Limitations and known bugs in version 3.0.
 mskerm.ed     MSKERM.ED     Detailed edit history of version 3.0.
 msvibm.vt     MSVIBM.VT     VT52/102/320/340/H19 terminal emulation summary.
 msvibm.tek    MSVIBM.TEK    Tektronix graphics summary (in preparation).
 mss*.asm,.h   MSS*.ASM,.H   System-independent source code.
 ms*ibm.asm    MS*IBM.ASM    IBM-PC/PS2-specific source code.
 msvibm.bat    MSVIBM.BAT    DOS batch program for building 3.0.
 msvibm.mak    MSVIBM.MAK    A makefile for building 3.0 under DOS with MASM.
 msvibb.mak    MSVIBB.MAK    A makefile for building 3.0 with Borland TASM.
 msvibx.mak    MSVIBX.MAK    A makefile for building 3.0 under Xenix.
 msvibm.lnk    MSVIBM.LNK    LINK command file for 3.0.

Kermit Init/Command Files:
 mskermit.ini  MSKERMIT.INI  Sample initialization file, includes DIAL macro.
 msihay.tak    MSIHAY.TAK    Hayes modem dialing script (used with DIAL).
 msiem*.ini    MSIEM*.INI    Keyboard setups for use with EMACS.
 msiwp3.ini    MSIWP3.INI    New keyboard setup for mainframe WordPerfect.

Utilities:
 mspeps.*      MSPEPS.*      Epson printer driver for EGA graphics screens.
 mspep4.*      MSPEP4.*      PC CP437-to-Epson character set translation.
 mspupc.sh     MSPUPC.SH     PCPRINT (transparent print) for UNIX.
 mspvpc.com    MSPVPC.COM    PCPRINT for VAX/VMS.
 msixse.*      MSIXSE.*      XSEND utility for sending directory trees.
 msuchk.*      MSUCHK.*      SCANCHEK utility to display keyboard scan codes.
 msulk2.*      MSULK2.*      LK250 keyboard driver.

Binaries are available on watsun only, for FTP in binary (image) mode,
in the kermit/bin directory:
 msvibm.exe    The MS-DOS Kermit 3.0 executable program.
 mspeps.com    Epson printer driver for EGA graphics screens.
 mspep4.exe    PC Code-Page-437-to-Epson character set translation.
 msixse.exe    XSEND utility for sending directory trees.
 msuchk.exe    SCANCHEK utility for keyboard scan codes.

Non-IBM Versions:

The non-IBM-compatible versions of MS-DOS Kermit 3.0 are not done yet.  Some
(DEC Rainbow, Heath/Zenith-100) are currently in preparation and will be
announced when they are ready.  Volunteers are needed for the others (Victor,
Sanyo, TI, HP, NEC, etc).  In the meantime, the new mss*.* source files are
incompatible with the old msu, msg, msx, msy, and msz system-dependent source
files for the non-IBM systems.  The .BOO files for the non-IBM versions,
however, will remain available.  Also, the old source files will be accessible
for limited time (most likely until the next major release of MS-DOS Kermit)
in kermit/old on watsun.

Bootstrapping:

For those who cannot use FTP to transfer the binary MSVIBM.EXE file
directly, the MSVIBM.BOO is an encoding of MSVIBM.EXE into printable ASCII
characters that should be safely transferrable over BITNET, e-mail, etc.
Use your old version of Kermit to download this file to your PC, and then
run any of the "BOO-file decoders" to translate it back into a runnable .EXE
file.  The following files are available for this purpose:

 msbaaa.hlp   An explanation of the bootstrapping files and procedures.
 msbpct.bas   A BOO-file decoder written in Microsoft BASIC.
 msbpct.c     Like MSBPCT.BAS, but written in C for speed.
 msbpct.boo   BOO file formed from MSBPCT.EXE based on MSBPCT.C.
 msbpct.*     There are also versions of MSBPCT in assembler, Fortran, etc.

If you have a C, Pascal, or other compiler, download the appropriate MSBPCT
source code, compile it, and run it to translate MSVIBM.BOO into MSVIBM.EXE.
If you only have BASIC, you should download MSBPCT.BAS and MSBPCT.BOO.  Then
use the former to create MSBPCT.EXE from the latter, and then use MSBPCT.EXE
to decode MSVIBM.BOO (using the BASIC version directly on MSVIBM.BOO would
take a very long time).

Our deepest thanks to Professor Joe R. Doupnik of Utah State University
([e-mail]) for the year of hard work he put in on this release, and for
his continuing devotion to the Kermit effort over the years.  Thanks also the
many others who contributed to 3.0, particularly Terry Kennedy, Jack Bryans,
John Junod, Bert Tyler, Mikko Laanti, Fred Richter, Hirofumi Fujii, Gary
Stebbins, Drew Derbyshire, and Paul Whitmer.  And for the accompanying
utilities, thanks to Mark Buda, Terry Kennedy, Phil Benchoff, Mark Zinzow, R.
Brooks Van Horn, and Frank da Cruz.

More about MS-DOS Kermit 3.0 in the following messages.

------------------------------

Date: Thu, 18 Jan 1990 13:12:11 EST
From: Christine M Gianone <[e-mail]>
Subject:  MS-DOS Kermit 3.0 Questions and Answers
Keywords: MS-DOS Kermit 3.0

Here are the questions that came up most frequently during the MS-DOS Kermit
3.0 beta testing period:

 Q - I tried using the Latin-1 (or DEC-MCS) terminal character set, but I
     didn't get any special characters on my screen, only incorrect ASCII
     characters where the special characters should be.

 A - To see 8-bit text characters, you need an 8-bit no-parity connection to
     the host, and you must tell MS-DOS Kermit to SET DISPLAY 8 (7 is the
     default).  In the 7-bit environment, you can still use an 8-bit character
     set if your host sends shift-in/shift-out codes (but see MSKERM.BWR).
     Otherwise you must use one of Kermit's 7-bit "national replacement
     character sets" (Italian, Norwegian, etc), in which brackets, vertical
     bars, etc, are replaced by national characters.

 Q - If none of Kermit's built-in terminal character is suitable for my
     language or computing environment, what can I do?

 A - Put a lot of SET KEY and SET TRANSLATE INPUT commands in your
     MSKERMIT.INI file.  These commands override Kermit's built-in
     translations of outbound and inbound characters, respectively.  Also
     remember to SET TRANSLATE INPUT ON.  Using these mechanisms, you can
     construct an entirely new terminal character set.

 Q - Word-11 or other DEC PDP-11 or VAX/VMS applications do not seem to work
     right with 3.0.  Screens are fractured, etc.

 A - Kermit's new VT320 terminal emulation is noticed DEC by operating systems
     like VMS 5.0 or later, causing them to send 8-bit control sequences which
     are ignored by MS-DOS Kermit unless you SET DISPLAY 8.  SET DISPLAY 7 is
     still the default, for compatibility with earlier releases.

 Q - If Kermit does VT340 graphics, how come my SAS graphs don't come out
     right if I tell SAS that I have a VT340?

 A - Kermit implements many VT340 graphics features, including colors and
     sixels, but not DEC's REGIS graphics language, which is what SAS uses.
     There are no current plans to implement REGIS, which is huge.  The
     VT340 features which are supported by Kermit can be used to best
     advantage with host-resident versions of WordPerfect (4.2 and 5.0) on
     VAX/VMS or UNIX.

 Q - Why do I have to SET FILE TYPE TEXT and SET FILE TYPE BINARY with 3.0
     when I didn't have to do this in previous versions?

 A - During file transfer, version 3.0 does two things that previous versions
     didn't do: text file character set conversion, and conveying and using
     the file type given in the file attribute packet.  If you want to
     approximate the old mode of operation, in which you did not have to (and
     indeed could not) give SET FILE TYPE commands, you can SET TRANSFER
     CHARACTER-SET TRANSPARENT (this is the default anyway) and SET ATTRIBUTE
     TYPE OFF.

------------------------------

Date: Mon, 15 Jan 90 10:34:09 EST
From: Frank da Cruz <[e-mail]>
Subject: New MS-DOS Kermit Book Available
Keywords: MS-DOS Kermit 3.0

Christine M. Gianone, who you know as the editor of the Info-Kermit Digest,
Manager of Kermit Development and Distribution at Columbia, designer of
recent extensions to the Kermit protocol, author of recent pieces in Data
Communications Magazine, PC Week, etc etc, has written a book on MS-DOS
Kermit 3.0:

  "Using MS-DOS Kermit", Digital Press, Bedford, MA (1990).

This book includes MS-DOS Kermit 3.0 for the IBM PC family on a 5.25-inch PC
diskette.  Printing should be complete by early- to mid-February.  The short
beta-testing period for 3.0 was due to the printing and binding deadline for
this book+disk package.

Chris's book is quite different from the earlier MS-DOS Kermit manuals.  It is
tutorial in nature, geared mostly towards the typical non-computer-expert PC
user.  It includes illustrated step-by-step instructions for program
installation and hooking up your cables and modems, an introduction to MS-DOS,
and chapters devoted to major Kermit topics including terminal emulation, file
transfer, server mode, international character sets, script programming,
features for people with disabilities, etc.  Every concept is illustrated by
examples.  A complete command reference is included, along with tables of PC
keyboard scan codes, Kermit keyboard verbs, and PC character sets, plus
glossary, index, etc.  The detailed technical appendices (escape sequences,
etc) found in the previous manuals are omitted; this information is (or will
be) available in other forms.  "Using MS-DOS Kermit" is an excellent
introduction to MS-DOS Kermit 3.0 and its new features, and the command
summaries and tables also make it a valuable reference.

The new book+disk package provides higher-quality documentation to a wider
audience.  Its tutorial approach will reduce the consulting burden on the
organizational help desk.  The book will give Kermit software a more "serious"
and professional image in the corporate and government sectors, and in the
press.  Ultimately, the result should be increased popularity for Kermit, new
inroads into the mass market, and some badly needed revenue for Kermit
Development and Distribution at Columbia to keep the Kermit project alive.
See the file MSKERM.HLP for availability and ordering information.

Of course, the Kermit software itself remains free, copyable, and sharable,
with source code openly available.  Online documentation is available too,
including:

  MSKERM.HLP - Expanded summary of MS-DOS Kermit 3.0 features and commands.
  MSKERM.BWR - The "beware" file, listing limitations, bugs, workarounds.
  MSR300.UPD - Description of the new features in 3.0.
  MSKERM.ED  - Detailed edit history since 2.32/A.
  MSVIBM.VT  - Description of terminal emulator escape sequences, keys, etc.
  MSVIBM.TEK - Description of graphics emulation features and escape sequences.
  MSKERM.DOC - The 2.32/A manual (long).  Also .MSS and .PS versions.
  MS*.ASM,.H - The source code! (very long).

All these files are new except for the 2.32/A manual (which still applies,
since 3.0 is backwards compatible with 2.32/A).  In addition, there are
numerous supporting files (contributed script programs, key mapping files for
various applications, notes and hints found in the Info-Kermit digest, etc).
Those who don't have access to the book should be able to find whatever
information they need in these files, and of course can tailor or combine
these documents to produce whatever local documentation they need.

------------------------------

Date: Wed, 17 Jan 1990 14:13:12 EST
From: Christine M Gianone <[e-mail]>
Subject:  MS-DOS Kermit 3.0 Feedback Wanted
Keywords: MS-DOS Kermit 3.0

How is MS-DOS Kermit 3.0 working for you?  We usually hear from you only if
you have problems.  We'd also like to hear about it when things are OK.

Please let us know how you like the new features of 3.0 -- international
character sets, VT320 emulation, the new graphics features, sliding windows,
etc.  Also let us know about any discoveries you have made: how to use the
program with local area networks, host graphics applications, character sets,
etc, that are not mentioned in the documentation.  And of course, your problem
reports and suggestions for additional features in future releases are always
welcome.

And if you have any interesting stories about how you or your organization
are using Kermit, please send them in for possible publication in forthcoming
issues of Kermit News (yes, the fourth issue is on the way!).

------------------------------

Date: Mon Jan 8, 1990, 19:16:46 EST
From: Christine M Gianone <[e-mail]>
Subject: Announcing HP-1000 Kermit Version 1.99D
Keywords: HP-1000, RTE Operating System

This is to announce version 1.99D of HP-1000 Kermit for the Hewlett-Packard
1000 series of computers with the RTE-6 and RTE-A operating systems, from
Paul Schumann of E-Systems, Inc, Greenville, Texas, USA.  This version
replaces version 1.98 of September 1986.  The major new feature is support
for the D-Series multiplexer and drivers.  The new files are available in the
"D" area of Kermit distribution:

  Distribution Name    Original Name     Description
   HPMKER.SRC           (many)            Fortran Source Code
   HPMKER.SUB           KERMIT.SBMT       Interex program submission form
   HPMKER.INS           KERMIT.ISTL       Installation instructions
   HPMKER.LOD           KERMIT.LOD        Loader command file
   HPMKER.HLP           KERMIT.TEXT       Plain text help file
   HPMKER.MAK           KERMIT.MAKE       Makefile

Binary files are not included, since these are not easily distributed on
industry-standard magnetic tapes or over networks.  According to the
installation instructions, these files can be generated from the Fortran
source (and in the case of the indexed help file, from KERMIT.TEXT).

The source code consists of many files concatenated into one single file,
HPMKER.SRC.  Within this file, each original file begins with a line like

<<< k6subs.ftn >>>

to show the original file name.  This file can be picked apart into its
original files with a text editor or a simple program.

Before attempting to build HP-1000 Kermit, be sure to reconstitute the
original source files, and to rename the HPMKER files back to their original
names shown above.  If you have trouble getting these files onto your HP-1000
or building Kermit from them, you can order a native HP-1000 tape containing
this program (including binaries) from Interex, the international HP user
group.

Many thanks to Paul Schumann for keeping this version of Kermit current,
and for contributing it to Kermit Distribution!

------------------------------

Date: Sat, 2 Dec 89 5:21:22 MET
From: Kristoffer Eriksson <[e-mail]>
Subject: Query: C-Kermit Treatment of Modem Signals
Keywords: C-Kermit

[Ed. - What follows is an excellent discussion of some of the issues that
are holding up release of C-Kermit 4F, which in turn is holding up release
of C-Kermit 5A.  The system-dependent aspects of C-Kermit are the result of
contributions from dozens of programmers all over the world in the form of
patches to patches, rather than a rational and consistent design effort.
The code under discussion is in the ckutio.c module, and has reached a level
of complexity that defies understanding and instills fear in anyone who would
modify it, for fear of breaking something else which cannot be tested.
Responses to Kristoffer and to Frank da Cruz, [e-mail],
from UNIX programmers who might be able to help untangle this mess would be
most appreciated.]

I have made some modifications to ckutio.c for some new features, which made
it necessary for me to try and understand how kermit handles O_NDELAY and
CLOCAL on System V, and the corresponding facilities on other systems. My
conclusion so far, is that Kermit does not handle them in a concistent manner,
at least that is what I think now.

Now, to be able to continue with my new features, I need to fix this. To do
that without breaking anything at the same time, I need your help. I need to
know which parts of the current behaviour are intended, and which are not. I
need to know the consequences for systems other that SysV, because that is the
only one I have experience with. I need to know the consequences for the
routines that call on ckutio.c of changes in it. I have studied ckucon.c and
ckudia.c, but there are some other routines that call ckutio.c, which I
understand much less. I know there are many systems with flawed or in other
ways strange tty drivers. I need to know any considerations that should be
made for those.

I'll describe my understanding of O_NDELAY and CLOCAL on SysV. Let me know if
you disagree. You usually use O_NDELAY in the open() call to open a tty device
without blocking until there is a carrier present on that port, in case the
device has modem control enabled as default.  When you operate a modem on that
port, you usually don't want to wait for a carrier, since most modems don't
provide a carrier until you have dialed somewhere to, which you can't do if
you can't talk to it.  Ok, many modems can be configured to alwayes provide a
carrier, but then you can't be disconnected automatically when the connection
eventually drops. Kermit uses O_NDELAY on the open() in ttopen() if you have
set a modem type prior to the "set line" that causes ttopen() to be called.

O_NDELAY also affects read()-ing from the device. If there is nothing to read
(empty input buffer or dropped carrier), read() will finish immediately
returning 0 (the return value maybe will change/has changed in V.3 or V.4, I
don't know). You might want this behaviour sometimes (tell me if you think
Kermit does want it), but usually it is much more convenient to use the
VMIN/VTIME timed read in SysV, and Kermit does use VMIN/VTIME. With O_NDELAY
you would have to constantly loop on read() until you receive something.

However, if you turn off O_NDELAY, and use the VMIN/VTIME settings that Kermit
does, you have to find some other way to make the device ignore the carrier
absence, if you are going to talk to your modem.  You use CLOCAL to do that.
You couldn't have used CLOCAL to open the tty to begin with, since CLOCAL is
set through the ioctl() interface, which only works on already open files. But
once you have opened the file, you can set CLOCAL, and unset O_NDELAY. Kermit
sets CLOCAL when you dial, through a ttpkt(..., DIALING, ...) call in ckdial()
in ckudia.c.

Once you are finished commanding the modem, and have established a connection
and a carrier, you can unset CLOCAL so you will get an EOF when the connection
goes down. Kermit does that with a ttpkt(..., CONNECT, ...) call at the end of
ckdial().

If you have a direct connection that always gives a carrier, you need never
set CLOCAL.

So far, all seems well. However, O_NDELAY is not always unset, only sometimes.
I think this is wrong. I think O_NDELAY shoule always be unset at some time
before beginning to dial or connect. ttopen() leaves O_NDELAY set. ttpkt() and
ttvt() (ttvt is used by for the "connect" command) unset O_NDELAY only when
called with flow==DIALING.  Thus, for a direct connection where you do not
dial prior to connecting, O_NDELAY will remain set, unless I'm very mistaken.

By the way, I have not found any place where ttvt() is called with the
parameter "flow" set to either CONNECT or DIALING, but ttvt() nonetheless
handles those cases. ttvt() looks to me like a mutated ttpkt(), so maybe those
cases where just left in by accident?  Can they safely be removed?

After unsetting O_NDELAY, these functions perform some "magic"
( close(open(...) ). What systems need such magic?

Can someone explain how myread() works, especially the part where the return
value after an empty read is dependent on whether you have set a modem type or
not (ttmdm) and the loop around myread() in ttinc()?  I find it a bit strange.
What does the return values mean? I wonder whether this might be an effect of
O_NDELAY remaining set sometimes?  The condition ttmdm == 0 may during some
phases coincide with O_NDELAY remaining set, but not always. Is that the
reason for testing ttmdm?

In the end, ttres() also unsets O_NDELAY, this time without any magic, but
only for UXIII, and only if ttmdm != 0 (you have set a modem type).  Is there
any other reason for this than as a late repair of the missing unset earlier?
ttres() is supposed to restore the tty to "normal".  I wonder what this
"normal" mode is? If "normal" is the mode it had before dialing an connecting,
I don't think it will restore O_NDELAY to that state. I'm tempted to suggest
that it should be left alone, and to other functions fixed to always unset it,
but I am not sure that is the intended state either. If some very early state
is intended, which might be the case if ttres() can be called in an very early
state, e.g. via ttclos() if you change lines without using the first line,
maybe O_NDELAY should be turned on again?

tthang() closes and reopens the tty, except on Xenix systems. This open of
courses also blocks for carrier on my system if the O_NDELAY flag is not used,
exactly like the very first open. The open is performed with the same fcntl
flags as the file had before being closed. O_NDELAY is a fcntl flag. But
O_NDELAY is not always set at this point. It has been unset if you have used
the dial command, as I outlined before. I have patched this to force O_NDELAY
on the open, and restore to the original state afterwards. Any comment?  Why
is the tty closed at all? Shouldn't it suffice to set a zero baud rate, just
as the manual says? (It does suffice on my system.)

When the last open file descriptor to the tty is closed, it resets the
communications parameters to defaults (especially after dialing, when HUPCL
has been set explicitely). That is why CLOCAL will not remain on to enable a
painless new open.

Is it wise to use the "flow" parameter of ttpkt() and ttvt() both for setting
XON/XOFF flow controll and for indicating DIALING/CONNECT mode? Will there
never be any clash? What mode is it when it is not DIALING or CONNECT?

On many systems there is another solution to the problem of how to open and
read without blocking for a carrier. They have more than one device name (or
can have them created with mknod) for the same tty port. One name enables
modem control by default, and the other disabled it. Kermit does not know
about these different names, so it just uses what the user gives it.

I have testet that on SCO Xenix. I think it behaves somewhat strange on that
system, and not to my liking. The driver simply ignores my setting of CLOCAL,
and only uses the default for that device name, always. Are other systems like
that, too, or is just that Xenix is strange as always?

I think that's most of what I had on my mind.

Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden
Phone:[phone] ! e-mail: [e-mail]
Fax:  [phone] ! or ...!{uunet,mcvax}!sunic.sunet.se!kullmar!pkmab!ske

------------------------------

End of Info-Kermit Digest
*************************